fix: log panel flickering in Grafana 12.3+ with newLogsPanel virtualization#174
Open
hatemosphere wants to merge 1 commit intoquickwit-oss:mainfrom
Open
fix: log panel flickering in Grafana 12.3+ with newLogsPanel virtualization#174hatemosphere wants to merge 1 commit intoquickwit-oss:mainfrom
hatemosphere wants to merge 1 commit intoquickwit-oss:mainfrom
Conversation
4 tasks
hatemosphere
force-pushed
the
fix/log-panel-flickering
branch
2 times, most recently
from
bd2b70f to
2e509c5
Compare
…zation
Grafana 12.3 introduced a virtualized log list (newLogsPanel, GA) that
caches row heights by LogRowModel.uid. The uid is derived from the frame's
"id" field: uid = "${refId}_${idField.values[row]}".
Three issues caused flickering:
1. No "id" field in frames → all rows shared uid "A_null" → height cache
oscillated between different row heights → infinite resetAfterIndex
loop (13k+ calls/sec = visible flickering). Fix: generate unique id
per row, matching ES behavior.
2. sortPropNames ignored shouldSortLogMessageField → logMessageField
sorted alphabetically instead of first → Grafana picked wrong body
field → wrong height measurement. Fix: match ES datasource behavior.
3. processResponse.ts injected synthetic $qw_message field, adding an
extra field to frames. Fix: remove injection, Go backend now handles
field ordering. Also fix data links spread bug (comma operator).
Additionally migrated from deprecated getDataProvider() to
getSupplementaryRequest() API, matching ES/Loki datasources.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
hatemosphere
force-pushed
the
fix/log-panel-flickering
branch
from
2e509c5 to
79efcf6
Compare
Author
|
@Platane hey, any chances you could look at this? with 12.3+ plugin is mostly unusable |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes log panel flickering/row overlap in Grafana 12.3+ caused by three issues in how the plugin returns data frames to Grafana's new virtualized log panel (
newLogsPanel, GA since 12.3).Root cause
Grafana 12.3 introduced a virtualized log list that caches row heights by
LogRowModel.uid. The uid is${refId}_${idField.values[row]}. Without anidfield, all rows shared uidA_null, causing the height cache to oscillate between different row heights in an infiniteresetAfterIndexloop (13k+ calls/sec = visible flickering).Additionally,
sortPropNamesignored theshouldSortLogMessageFieldparameter, sologMessageFieldwas sorted alphabetically instead of being placed first. Grafana picks the log body viagetFirstFieldOfType(FieldType.string), so wrong field order = wrong body field = wrong height measurement.Changes
pkg/quickwit/response_parser.go:idfield per log row (sequential index as fallback when doc has noid), matching Elasticsearch behavior where each hit has_id/id. Grafana'sparseLegacyLogsFrameuses this forLogRowModel.uid, which the virtualizer uses as height cache key.sortPropNamesto actually sortlogMessageFieldto first position whenshouldSortLogMessageFieldis true, matching the Grafana built-in Elasticsearch datasource implementation.src/datasource/processResponse.ts:$qw_messagefield injection — now redundant since Go backend correctly sortslogMessageFieldfirst.[...(a || [], b)](comma operator, drops existing links) →[...(a || []), ...b].src/datasource/supplementaryQueries.ts:getDataProvider()togetSupplementaryRequest()API. The old code created an Observable that emitted{data: []}on every subscription. Matches how Grafana's built-in ES and Loki datasources work.Test plan
resetAfterIndexcalls vs 13k+/sec for QW)idfield → unique uids → no more infinite loop → no flickeringmessagefield correctly sorted to first position in frame